我們目前成功打造了能夠接收各種輸入（網頁、PDF、YouTube），並透過 Gemini 進行摘要與分類的系統。目前，AI 已經能穩定輸出包含 tldr、key_points、terms、tags 與 category 的 JSON 格式。

但問題來了：這份 JSON 只是「AI 對文章內容的理解」，它還不足以直接存入資料庫。一份完整的「知識檔案」不能只有內容，還需要包含「Metadata」，例如這篇文章的原始網址是什麼？是哪一天存入的？標題是什麼？如果我們直接把 AI 的產出丟進下一個節點，系統會因為缺少這些外部上下文而無法建立完整的知識庫。

在 AI 自動化系統中，我們必須意識到一個關鍵轉換：AI Output 不只是給人看的文字，它還要成為下一個 Workflow Node 可以使用的資料。
為了解決這個問題，我們需要設計一個 Knowledge Schema。這就像是定義一張資料庫的資料表，我們要把「AI 產出的語意資料」與「系統產生的 Metadata」結合起來，打包成一個標準化的資料物件，為明天將知識寫入 Notion 做好準備。

這個步驟發生在 AI 處理完畢後，即將觸發實際行動之前。

根據我們的系統需求，我們預計設計的知識資料結構需要包含以下欄位：

• Title：文章或影片的原始標題。
• TLDR：來自 AI 輸出的 tldr。
• Key Points：來自 AI 輸出的重點陣列 key_points，可轉換為條列式字串。
• Technical Terms：來自 AI 輸出的 terms。
• Tags：來自 AI 輸出的 tags。
• Category：來自 AI 輸出的分類 category（例如 DevOps、Backend 等）。
• Source：觸發 Workflow 的原始網址或檔案名稱。
• Created Time：系統處理完成的當下時間戳記。

如何在 n8n 中實作這層轉換？
我們可以在 n8n 接收到 FastAPI 回傳結果的 HTTP Request 節點後方，新增一個 Edit Fields (Set) 節點。在這個節點中，我們將分散在不同節點的資料聚合起來：

1. 從最源頭的 Webhook 節點提取原始的輸入網址 {{ $node["Webhook"].json.body.text }} 填入 Source。
2. 從 AI 回傳的節點提取 {{ $json.data.tldr }} 填入 TLDR。
3. 利用 n8n 內建的時間變數 {{ $now }} 填入 Created Time。
4. 將陣列格式的 Key Points 透過 Expression 轉換為字串，例如：
   {{ $json.data.key_points.join('\n') }}。

透過這個 Set 節點，我們將機率性的 AI 輸出與確定性的系統狀態，完美揉合成一份符合資料庫規格的標準 Payload。